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REMARKS 

This amendment is responsive to the Final Office Action dated September 9, 2009. 
Claims 3-6, 28-30, 52, 53 and 55 were previously cancelled. Claims 1, 2, 7-27, 31-51, 54 and 
56-59 are pending. 

Claim Rejection Under 35 U.S.C. $ 102 

In the Final Office Action, the Examiner rejected claims 1, 2, 7-27, 31-51, 54 and 56-59 
under 35 U.S.C. 102(e) as being anticipated by Ho et al. (US 6,910,148). AppHcant respectfully 
traverses the rejection. Ho et al. (US 6,910,148) fails to disclose each and every feature of the 
claimed invention, as required by 35 U.S.C. 102(e), and provides no teaching that would have 
suggested the desirability of modification to include such features. 

As one example. Ho et al. (US 6,910,148) fails to teach or suggest a method comprising 
managing state information within a primary control unit included within a device, wherein the 
state information comprises information representing a current state of one or more 
consumers included within the device, wherein managing the state information comprises (i) 
managing the state information within a temporally-ordered data structure, (ii) utilizing, for each 
of the consumers, a commit proposal and a commit marker pair within the temporally-ordered 
data structure to identify a portion of the state information for each of the consumers and 
(iii) setting, for each of the consumers, the corresponding one of the commit markers to identify 
a most recent object of the temporally-ordered data structure that has been communicated to and 
for which an acknowledgement has been received fi-om the respective one of the consumers, as 
recited by Applicant's claim 1 . That is. Ho lacks any teaching to suggest that state information 
comprises information representing a current state of one or more consumers included within the 
device or that a commit proposal/commit marker pair identifies a proition of the state 
information for each of the consumers. 

Instead, Ho describes an active controller that replicates a "routing protocol state change" 
to a standby controller.^ FIG. 1 of Ho shows an exemplary network in which this replication may 
occur within a redundant node having this redundancy platform (e.g., the active and standby 

' Column 4, lines 50-51. 
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controllers).^ This so-called "redundant node" that includes the redundancy platform by which 
to implement the Ho techniques is interconnected with a plurality of peer nodes.^ These peer 
nodes and the redundant node represent network devices, such as, "for example, network routers 
performing IP layer 3 services."'' These various devices maintain consistent routing and routing 
protocol state information by exchanging routing protocol messages with one another identifying 
the state changes.^ After making the state change identified in the message received from an 
external peer node to the protocol information (or persistent data, session states and routing 
table), the active card replicates the state change to the standby controller.^ In this respect, the 
routing protocol state changes are consumed by the active controller not by a consumer separate 
from the active controller. After consuming the routing protocol state changes, the active 
controller then replicated to the standby controller. 

Applicant's claim 1, to the contrary, requires the primary controller to manage state 
information that comprises information representing a current state of one or more 
consumers included within the device. That is, in the invention set forth by Applicant's claim 
1, the primary control unit is not the consumer of the state information but rather one or more 
consumers separate fi"om the primary control unit within the device (in which the primary control 
unit resides) consume the state information. Yet, the state changes in Ho are for and consumed 
by the active controller, not for and by the consumers, as required by Applicant's claim 1 . 

Consequently, Ho lacks any teaching to suggest a method comprising managing state 
information within a primary control unit included within a device, wherein the state 
information comprises information representing a current state of one or more consumers 
included within the device, wherein managing the state information comprises (i) managing the 
state information within a temporally-ordered data structure, (ii) utilizing, for each of the 
consumers, a commit proposal and a commit marker pair within the temporally-ordered data 
structure to identify a portion of the state information for each of the consumers and (iii) 
setting, for each of the consumers, the corresponding one of the commit markers to identify a 
most recent object of the temporally-ordered data structure that has been communicated to and 

^ Column 5, lines 29-34. 
^ Column 5, lines 29-34. 
Column 5, lines 38-47. 

* Column 6, lines 12-20; and column 26, line 50-52 ("For example, a peer node can send redimdant node 104 that a 
BGP route is no longer available as a state change.") 

* Column 9, lines 9-16. 



3 



Application Number 10/678,280 

Response to Office Action mailed September 9, 2009 

for which an acknowledgement has been received from the respective one of the consumers, as 
recited by Applicant's claim 1. 

Second, Ho does not describe any technique with respect to communicating state data 
from a primary controller to consumers of state data that are located within the same device, as 
required by Applicant's claim 1. As noted above, FIG. 1 of Ho provides an example where peer 
nodes external from the primary device send routing protocol state changes to the redundant 
node. The redundant node may then generate state changes and send these state changes to the 
peer nodes, whereupon the peer nodes consume the routing changes.^ This portion of Ho 
describes communicating routing protocol changes between routers and is irrelevant to 
techniques for communicating device state data from a primary controller of a device to other 
components that consume state information within a device. In Ho, these peer nodes are 
external from the redundant node and not included within the same device as the primary control 
unit, contrary to the requirements of Applicant's claim 1 . Accordingly, Ho also lacks any 
teaching to suggest Applicant's technique with respect to communicating state data to consumers 
are included within the same device as the primary control unit, as required by Applicant's claim 
1. 

On this point, in the current Final Office Action, the Examiner indicates, in item B) under 
the heading "Response to Arguments," that "consumers are clearly taught by Ho, where interior 
nodes of redundant node can maintain routing state information and represent routers that are 
used to forward information (col. 5, lines 49-56)." This is an improper construction of the Ho 
reference. The "interior nodes" as characterized by the Examiner, in fact, refer to the above 
described peer nodes, which the Examiner correctly acknowledges represent routers (or, more 
generally, network devices). However, it is improper to construe peer nodes as being different 
components included within the redundant node, as asserted by the Examiner. It is clear from 
FIG. 1, which Applicant reproduces below for the Examiner's benefit, that these peer nodes are 
not included within the redundant node as suggested by the Examiner; peer nodes 102A, 102B 
reside external from redundant node 104 in the following FIG. 1 : 



Column 6, lines 12-20. 
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In this respect, FIG. 1 of Ho does not even so much as suggest that peer nodes are internal to the 
"node with redundancy platform." It is therefore improper for the Examiner to suggest that the 
peer nodes represent interior nodes of the redundant node. Ho, as shown above, lacks any 
teaching to suggest that the consumers are included within the same device as the primary 
control unit, as required by Applicant's claim 1. 

Third, Ho further lacks any teaching to suggest managing the state information within a 
temporally-ordered data structure, as further required by the method of Apphcant's claim 1 . Ho 
is silent with respect to this aspect of Applicant's claim 1 . In the current Final Office Action, the 
Examiner indicates, in item A) under the heading ''Response to Arguments" that the routing 
table shown in FIG. 4B of Ho suggests a temporally-ordered data structure. Contrary to the 
Examiner's assertion, there is no evidence in the record to suggest that a routing table is not a 
temporally-ordered data structure. According to Ho, a routing table stores information that 
defines "routes known by a node for each routing protocol."^ Ho further states that "a router 
generates and maintains a routing table of available routes known to the router," which then 
"uses the routing table to create a forwarding information table (FIB)."^ Thus, as is conventional 
in the art, the Ho routing table reflects the current topology of the network by defining the 
"routes known by a node for each routing protocol." This is not a "temporarily ordered" data 
structure, as required by claim 1 . In Ho, there is no suggestion that the components of the 
routing table are, for example, stored in an order that is a function of time, i.e., that the entries in 
the routing table are arranged in any temporal order. Instead, this portion of Ho make clear that 
the routing table is a representation only of the current state of the network, i.e., the routes that 

* Column 9, lines 29-32. 
' Column 1, lines 27-32. 
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are currently known. Besides the above limited characterizations of a routing table cited by the 
Examiner, Ho is silent with respect to the actual structure of the routing table and certainly 
provides no teaching to suggest that a routing table represents the temporally-ordered data 
structure required by Applicant's claim 1. 

Applicant reproduces FIG. 3 A of Applicant's specification below to illustrate one 
example of temporally ordered data structure. 



..-446 ,.-44C ^.-UD ,.-ME 



OSJECT 




OBJECT 




OBJECT 




OBJECT 




OBJECT 


CM 1 

4mI 


4t>A 




4€S 




CM 1 CM 
43B 43C 


4fiC 


1 CP 1 


1 " 

460 


'cp] 1 CP 

ml lac 



52A-- 



FIG. 3A 

In FIG. 3A, the objects maintain state data and are linked to one another via temporal pointers 
46A-46D. The term "temporal" is used with respect to the example of FIG. 3 A to denote time- 
based ordering among the objects. To illustrate, object 44A may be said to have come before 
object 44B with respect to the temporal or time-based order. Thus, to update a corresponding 
consumer with the state changes stored to object 44A and object 44B, the order indicates that 
first state change stored to object 44 A came before the second state change stored to object 44B 
in terms of a position in time when the state was received or generated. Using this temporally- 
ordered data structure, the active controller may control issuing the state change stored to object 
44A to a consumer before sending the state change stored to object 44B. In this respect, FIG. 3 A 
illustrates a temporally-ordered data structure where the arrangement of the stored data provides 
an indication of a position in time when the data was generated or received. 

To the contrary, the routing table generally referred to in Ho comprises a table reflecting 
only current status of routes. There is no evidence to suggest any temporal aspect to the Ho 
routing table, e.g., one entry in the table is not temporally-ordered with respect to another entry. 
Instead, each entry in the routing table reflects a known route that is currently available within 
the network. Each entry is maintained to provide a current view of the network. Maintaining 
past routes that were available in the network within a routing table and linking these past routes 
to current routes would not facilitate routing. Routing requires knowledge only of the current 
state of the routes within the network, not past states. A routing table therefore does not define a 
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temporal-ordering between entries in the routing table and therefore does not represent a 
temporally-ordered data structure, contrary to the Examiner's assertions otherwise. 

For at least these reasons, this construction of a routing table as representative of the 
temporally-ordered data structure required by Applicant's claim 1 is improper. Accordingly, Ho 
lacks any teaching to suggest managing the state information within a temporally-ordered data 
structure, as further required by the method of Applicant's claim 1 . 

Fourth, Ho also fails to teach or suggest utilizing, for each of the consumers, a commit 
proposal and a commit marker pair within the temporally-ordered data structure to identify a 
portion of the state information for each of the consumers, as required by Applicant's claim 1. 
That is, claim 1 requires that the replicated state data itself include commit proposals and commit 
markers within the temporarily-ordered data structure. Ho is silent with respect to the 
temporally-ordered data structure, as shown above. In addition. Ho is entirely silent with respect 
to a commit proposal and a commit marker pair within the temporally-ordered data structure. 
The Examiner indicates in the rejection of previously cancelled claim 5 (which is presented in 
the current Final Office Action) that column 11, lines 1 1-49 of Ho teaches or suggests utilizing a 
commit proposal and a commit marker pair within the temporally-ordered data structure. 
Applicant disagrees, reiterating remarks made in a previous amendment to the Office Action 
mailed October 21, 2008 and Notice of Non-Compliant Amendment mailed April 17, 2009. 

Ho, when properly understood, teaches to an active controller that replicates routing 
protocol state changes to a standby controller.^" Column 11, line 11 through column 12, line 38 
of Ho teach to how this replication proceeds and the Examiner cites this portion to contend that 
Ho teaches to a temporally-ordered data structure and utilizing commit proposal / commit marker 
pairs to identify a portion of the state information. Yet, Ho teaches in column 11, lines 11-15 that 
the active card receives a message fi-om a peer node to which the peer node requires a response. 
This peer node, according to column 11, lines 15-17 of Ho, needs to hear a confirmation that the 
redundant node received the update and is making the necessary changes "(i.e., committing to 
the message)." Apparently, the Examiner reUes on Ho's use of the term "committing," as 
evidence of teaching a temporally-ordered data structure and utilizing commit proposal / commit 
marker pairs within that same data structure, as required by Applicant's claim 1 . Mere 

'"Column 4, lines 50-51. 
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suggestion by a routing device of "committing to the message" is not a sufficient basis on which 
the Examiner can rely to suggest the particular way in which Applicant's replication occurs. 
There fails to teach the elements of a commit proposal and a commit marker pair at all, let alone 
that such structures would be used within the temporally-ordered data structure. 

Ho continues throughout the rest of column 1 1 from lines 1 7-49 to establish that the 
standby card "must commit to message[s] committed by [the] active card." Ho, yet again, fails 
to suggest how the standby card commits to the messages committed by the active card, and 
certainly nothing in this portion suggests that committing to the messages occurs by (i) 
replicating the temporally-ordered data structure within the standby control unit and (ii) 
replicating the commit proposal and the commit marker to the standby control unit, as further 
recited by AppUcant's claim 1. 

In fact, column 11, lines 50-62 of Ho explicitly describes a substantially different method 
by which to repUcate state changes. Ho, in this portion, states that "after receiving MSG A, 
active card 910 sends message A to standby card 950." Sending a message detailing the update 
or state change is substantially different from replicating the temporally-ordered data structure 
within the standby control unit and replicating the commit proposal / commit marker pairs to the 
standby control unit, as required by Applicant's claim 1 . Ho continues in this cited portion to 
suggest that the standby card then acknowledges MSG A, and only upon receiving this 
acknowledging does the active card commit to the message and send the commitment to the 
remote peer. In no way is it reasonable to construe this as the same as the replicating limitations 
required by Applicant's claim 1 . 

In the current Final Office Action, the Examiner responds to this argument in item A) 
under the heading ''Response to Arguments" by noting that column 8, lines 2-27 of Ho relate to 
"a redundancy platform is user[sic] to 'replicate or copy current configuration information, 
global information, routing table information, forwarding table information, protocol sessin 
information, or database information in the active card to the standby card.'" (Emphasis 
Examiner's) From this the Examiner concludes that it is "clear that Ho reads upon the limitation 
of temporally-ordered data structure and wherein communicating the change comprises 
replicating the temporally-ordered data structure within the standby control unit and replicating 
the commit proposal and commit market to the standby control unit. . ." 
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Applicant can find no mention of a commit marker or a commit proposal within this cited 
portion of Ho. Mere reference to a routing table and replication of a routing table from an active 
to a standby card is not sufficient to teach, much less suggest, either a commit marker or a 
commit proposal, let alone utilizing, for each of the consumers, a commit proposal and a 
commit marker pair within the temporally-ordered data structure to identify a portion of the 
state information for each of the consumers, as required by Applicant's claim 1 . Still further, 
this reference to a routing table and replication thereof by an active controller to a standby 
controller is not sufficient to teach, much less suggest (i) replicating the temporally-ordered data 
structure within the standby control unit and (ii) replicating the commit proposal and the commit 
marker to the standby control unit, as further recited by Applicant's claim 1 . 

Fifth, Ho lacks any teaching to suggest utilizing, /or each of the consumers, a commit 
proposal and a commit marker pair within the temporally-ordered data structure to identify a 
portion of the state information for each of the consumers, as required by Applicant's claim 1. 
That is, claim 1 specifically requires a commit proposal and a commit marker par for each 
consumer, and that the commit proposal and commit marker pair are located within the 
temporally-ordered data structure of state information. Ho is silent with respect to cither a 
temporally-ordered data structure or a commit proposal and a commit marker pair within the 
temporally-ordered data structure. Moreover, Ho lacks any teaching to suggest that the commit 
proposal and commit marker pair for each consumer in the manner required by Applicant's claim 
1. 

With respect to this point, the Examiner indicates in item C) under the heading 
''Response to Arguments" that a forwarding table taught by Ho can be construed as a consumer. 
Given this construction, presumably Ho would then teach, according to the Examiner's logic, to 
utilizing, for the forwarding table, a commit proposal and a commit marker pair within the 
routing table, where the pair denote state changes to identify a portion of the state information 
within the routing table that has been communicated to and for which acknowledgement has 
been received from the forwarding table. Yet, Applicant can find no mention in Ho of this 
teaching or any suggestion to indicate such a teaching. The Examiner cannot presume such a 
teaching exists without actually providing some explanation as to how the Examiner arrived at 
this construction. 
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To the extent independent claims 16, 24, 42 and 51 recite limitation similar to that of 
claim 1 upon which the above arguments are predicated, the above arguments apply to 
independent claims 16, 24, 42 and 51. 

The arguments made above with respect to independent claims 1,16, 26, 42 and 51 also 
apply to claims 2, 7-15, 17-25, 27, 31-41, 43-50, 54 and 56-59 by virtue of these claims 2, 7-15, 
17-25, 27, 31-41, 43-50, 54 and 56-59 depending from respective claims 1, 16, 26, 42 and 51. 

Ho fails to disclose each and every limitation set forth in claims 1, 2, 7-27, 31-51, 54 and 
56-59. For at least these reasons, the Examiner has failed to establish a prima facie case for 
anticipation of Applicant's claims 1, 2, 7-27, 31-51, 54 and 56-59 under 35 U.S.C. 102(e). 
Withdrawal of this rejection is requested. 



All claims in this application are in condition for allowance. Applicant respectfully 
requests reconsideration and prompt allowance of all pending claims. Please charge any 
additional fees or credit any overpayment to deposit account number 50-1778. The Examiner is 
invited to telephone the below-signed attorney to discuss this application. 



CONCLUSION 



Date: ^November 9, 2009_ 

SHUMAKER & SIEFFERT, P.A. 
1625 Radio Drive, Suite 300 
Woodbury, Minnesota 55125 
Telephone: 651.286.8367 
Facsimile: 651.735.1102 



By: /Matthew K. Gage/ 
Name: Matthew K. Gage 
Reg. No.: 63,059 



10 



